home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5710 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.1 KB  |  84 lines
  1. Path: infoserv.rug.ac.be!asterix
  2. From: ward.debacker@rug.ac.be (Ward De Backer)
  3. Newsgroups: comp.lang.c++
  4. Subject: Visual C++ 4.0 DLL's for Win95 and Visual Basic 4.0
  5. Date: Tue, 06 Feb 96 20:08:42 GMT
  6. Organization: JLG AUTOMATION
  7. Message-ID: <4f7ncl$998@infoserv.rug.ac.be>
  8. NNTP-Posting-Host: asterix.iic.rug.ac.be
  9. X-Newsreader: News Xpress Version 1.0 Beta #4
  10.  
  11. When I develop applications for Windows, I normally use Visual Basic for the 
  12. interface stuff and a DLL written with Visual C++ for the underlying 
  13. algorithms. I have always developed applications for Windows 3.11.
  14.  
  15. Lastly, I tested the new Visual C++ 4.0 compiler for Windows 95. I wrote a 
  16. 32bit DLL with a simple testfunction in it. On the other side, I wrote a small 
  17. program in Visual Basic that calls this subroutine. The First major difference 
  18. I found was that the basic types of Visual Basic and Visual C++ are no longer 
  19. compatible (i.e. consistent) because an "Integer" in VB is 16 bit wide and a 
  20. standard int in VC++ is 32 bit wide in win95 (unless you declare it as int16). 
  21. But this was not the major problem. When I tried to test my function by 
  22. running my VB program, I couldn't get it to work by no means. Visual Basic 
  23. either didn't find my DLL function or issued a "bad calling convention" 
  24. message. Finally, I inspected my DLL executable with the dumpbin utility. To 
  25. my surprise, I saw a totally different way of naming exported functions. 
  26. Microsoft now uses so called "decorated names" for exported functions. This 
  27. means that a function name is appended with a "@" and the number of bytes on 
  28. the stack the function parameters occupy.
  29.  
  30. So far, so good. But the problem now is that Visual Basic doesn't recognise 
  31. these decorated names in your DLL. As a consequence, you have to declare all 
  32. the DLL functions with a decorated alias.
  33.  
  34. To show clearly what's going on, I present an example here:
  35.  
  36. In Windows 3.11, you wrote in Visual Basic:
  37.  
  38. Declare Function Test Lib "test.dll" (Byval i As Integer) As Integer
  39.  
  40. In Visual C++, the declaration could have been this:
  41.  
  42. extern "C" int FAR PASCAL _export Test(int i)
  43. {
  44.   ...
  45. }
  46.  
  47. Now, in Windows 95, Visual Basic 4.0: (only long variables are now type 
  48. compatible)
  49.  
  50. Declare Function Test Lib "test.dll" Alias "_Test@4" (Byval l As Long) As Long
  51.  
  52. In Visual C++ 4.0, the declaration is this:
  53.  
  54. extern "C" __declspec( dllexport ) long pascal Test(long l)
  55. {
  56.   ...
  57. }
  58.  
  59. Remark the differences:
  60.  
  61. - FAR disappeared (of course because segmentation is no longer needed)
  62. - _export is replaced by __declspec (as specified in the Microsoft   
  63. documentation)
  64. - pascal remians necessary because of the use in Windows of the pascal calling 
  65.   convention.
  66.  
  67. I tested this alos with Excel 7.0 on Windows 95 (in VBA): same results.
  68.  
  69. My question is: is it not possible to get rid of those funny decorated names ?
  70. (are there possibilities to circumvent this limitation).
  71. Or am I doing things completely wrong ???
  72.  
  73. Is there anyone who has had the same experience ?
  74.  
  75.  
  76.  
  77. Ward De Backer   -   JLG AUTOMATION
  78.   Technologiepark Zwijnaarde, 3
  79.   B-9820 ZWIJNAARDE  -  BELGIUM
  80.  
  81. E-mail: ward.debacker@rug.ac.be
  82. FTP-server: asterix.iic.rug.ac.be
  83.             anonymous login possible
  84.